Web Service Interfaces’ 


Dirk Beyer 
EPFL, Lausanne, Switzerland 


dirk.beyer@epfl.ch 


ABSTRACT 


We present a language for specifying web service interfaces. 
A web service interface puts three kinds of constraints on 
the users of the service. First, the interface specifies the 
methods that can be called by a client, together with types 
of input and output parameters; these are called signature 
constraints. Second, the interface may specify propositional 
constraints on method calls and output values that may oc- 
cur in a web service conversation; these are called consis- 
tency constraints. Third, the interface may specify temporal 
constraints on the ordering of method calls; these are called 
protocol constraints. The interfaces can be used to check, 
first, if two or more web services are compatible, and second, 
if a web service A can be safely substituted for a web ser- 
vice B. The algorithm for compatibility checking verifies that 
two or more interfaces fulfill each others’ constraints. The 
algorithm for substitutivity checking verifies that service A 
demands fewer and fulfills more constraints than service B. 


Categories and Subject Descriptors 


D.2.1 [Software Engineering]: Require- 
ments/Specifications; D.2.4 [Software Engineering]: 
Software/Program Verification—Formal methods, Model 


checking; D.2.12 [Software Engineering]: Interoperabil- 
ity—Interface definition languages 
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1. INTRODUCTION 


Interface formalisms are used to avoid errors in 
component-based system design. In particular, by check- 
ing at design-time if two or more interfaces are compatible, 
we can ensure that the corresponding components work to- 
gether properly at run-time. For example, programming- 
language types offer a simple interface formalism: it can be 
checked at compile-time if the number and types of the pa- 
rameters of a function call and the function definition match. 
Richer interface formalisms have been devised for software 
components whose correct interaction depends on commu- 
nication protocols [7], timing [9], or resource use [5]. 

Web services offer a particularly natural and important 
application domain for interface formalisms. A web service 
often depends on other web services, which have been im- 
plemented by different vendors, and their correct usage is 
governed by rules. Such rules may constrain data types, but 
they may also express temporal constraints (e.g., “a ship- 
ping order should be placed only if a credit card check has 
succeeded”). We present a language for equipping web ser- 
vices with interfaces that formalize such rules. The benefits 
of our language are two-fold. First, it can be checked algo- 
rithmically if two or more interfaces fulfill each other’s rules; 
in this case the interfaces are called compatible. Second, it 
can be checked algorithmically if one interface can be safely 
replaced by another one; in this case the latter interface is 
said to refine the former. 

Compatibility and refinement checks, like model check- 
ing, reduce the burden on testing for system integration and 
validation. However, we explicitly propose to use formal 
methods to specify and verify the interfaces of web services, 
not their implementations (for implementation checking see, 
e.g., [13, 15, 11, 20]). Interface checking stands a much bet- 
ter chance of succeeding in practice than implementation 
checking, as interfaces are usually less complex than the cor- 
responding implementations. Indeed, good interface design 
suggests that an interface exposes all information about a 
web service that is needed to use the service properly, and 
that the interface does not expose more than that. This is 
why we offer not one, but three interface languages, which 
are increasingly more expressive. 

The first language, called web service signatures, ex- 
poses only the names and types of externally callable meth- 
ods and their return values. For example, a web ser- 
vice signature may offer the method credit_card_check 
with the two return values success and failure. The 
second language, called consistency interfaces, equips web 
service signatures with propositional constraints on the 


consistency between various method calls and return val- 
ues. For example, it may be inconsistent to have both 
(credit_card_check, failure) and (ship_order, success) 
in the same web service conversation. The third and rich- 
est language, called protocol interfaces, equips web ser- 
vice signatures with temporal constraints between method 
calls. For example, a protocol interface may prohibit 
conversations where (ship_order,success) occurs before 
(credit_card_check, success). 

The compatibility and refinement of web service signa- 
tures can be type checked. Consistency interfaces are state- 
less; their compatibility and refinement can be checked by 
solving propositional (boolean) constraints. Protocol inter- 
faces are stateful; they can be naturally expressed by au- 
tomata (state machines) with nondeterminism, recursion, 
and thread creation. Their compatibility can be checked by 
model checking temporal safety constraints. 


2. WEB SERVICE SIGNATURES 


Let M be a finite set of web methods and O be a finite 
set of outcomes. The outcome is used to encode a return 
value from the web method, or other behavioral differences 
between various calls to the web method; for instance, if the 
invocation will lead to a call to a callback method or not. 
An action a on M and O is a pair (m,o) € Mx O. An 
action (m, o) constitutes an “assumption” at the invocation 
point that the call to web method m will eventually lead 
to the outcome o for this call. This coupling of the call 
together with its eventual outcome is found to be very useful 
in reasoning about the behavior of web services. The set of 
actions on M and O is denoted by AC M x O. 

A web service signature S is a partial function S : A > 2^, 
which assigns to an action a a set of actions which can be 
invoked by a. A web service signature S supports an action 
a € A if S(a) is defined; S supports a web method m € M if 
some action (m,o) is supported by S. An action a requires 
an action a’ in S if a’ € S(a). A web service signature 
S requires an action a’ if some action a requires action a’ 
in S. A web service signature S is well-formed if for every 
web method m supported by S, every action (m,o) € A 
required by S is supported by S. In the rest of the paper, 
the word “signature” stands for “well-formed signature”. 

Intuitively, a signature element ((m, 0), 5) says that when 
the web method m is called, and the caller assumes the out- 
come o, this signature pledges to support this action, and 
itself relies on that the assumptions carried by the actions 
a’ € S are fulfilled (by either this signature, or by the envi- 
ronment). Thus, a web service signature relates the “guar- 
antees” made (actions supported) by the interface to the 
“assumptions” (actions assumed to be supported, either by 
the interface itself or by the environment) under which they 
are made. The signature is well-formed if the assumptions 
and guarantees are mutually consistent. 


EXAMPLE 1. (Supply chain management applica- 
tion) We briefly describe a supply chain management ap- 
plication [2] that we will use as a running example in the 
rest of the paper to illustrate concepts as we introduce them. 
The application consists of five web services: Shop, Store, 
Bank, Transport, and Supplier. We will present interface 
models for Shop and Store in the following sections. We will 
focus on particular aspects of the services and not provide 
a full-fledged model. 
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GetOffer 


ChkAvail 


Figure 1: The supply chain management application 


Figure 1 gives an overview of the interactions between the 
web services. The Shop interface supports the web method 
SellItem which is called by the Client application to start 
the selling process, and it supports ChkAvail which is a 
subroutine (called by Shop itself) that checks availability 
of items for sale. Shop requires the web method ChkStore 
to be implemented by Store to check whether the desired 
items are available in stock. It also requires ShipItem to be 
implemented by Transport to ship the sold items to the cus- 
tomer, and it requires ProcPay to be implemented by Bank 
to process credit card payments. Store requires two web 
methods to be implemented by Supplier: GetOffer and 
Order, to get an offer for an item, and to order new items if 
the stock falls below a certain threshold. | 


EXAMPLE 2. (Well-formed signature) To model the 
Shop we need the following sets of methods, outcomes and 
actions, before we can define a web service signature for it: 


M = {SellItem, ChkAvail, ChkStore, ProcPay, ShipItem, 
GetOffer, Order} 

O = {SOLD, NOTFOUND, OK, FAIL, REC} 

A = {(SellItem, SOLD), (SellItem, FAIL), 

(Sel11Item, NOTFOUND), (ChkAvail, OK), (ChkAvail, FAIL), 

(ChkStore, OK), (ChkStore, FAIL), (ProcPay, OK), 

(ProcPay, FAIL), (ShipItem, OK), (ShipItem, FAIL), 

( 


GetOffer, REC), (Order, OK) } 


The Shop interface can be modeled as the following web 
service signature: 


Sshop = { 

(SellItem, SOLD) +> ChkAvail, OK), (ProcPay, OK), 
ShipItem, OK) } 
ChkAvail, OK), (ChkAvail, FAIL), 


( 
} 
(ProcPay, OK), (ProcPay, FAIL), 
( 
( 
( 


{ 
(SellItem, FAIL) > { 
ShipItem, FAIL) } 


ChkStore, OK) } 
ChkStore, FAIL)} 


(ChkAvail, 0K) + 
(ChkAvail, FAIL) > 


} 


For instance, action (SellItem,SOLD) is supported 
by Sshop, and actions (ChkAvail, 0K), (ProcPay, 0K) and 
(ShipItem, OK) are assumed to be supported by the environ- 
ment. Signature Sspop is well-formed, because it supports 
all possible actions for its supported methods. | 


AS 


Compatibility and composition. For two web service 
interfaces, we want to check whether they can cooperate 
properly, i.e., whether their signatures mutually fulfill their 
guarantees and assumptions. 


Given two web service signatures Sı and S2 with 
dom(S;) N dom(S2) = @, if Se = Sı U S2 is well-formed, 
then Sı and S2 are compatible (denoted by comp(Sj,S2)), 
and their composition (denoted by S1 || S2) is Se. The com- 
position operation is commutative and associative. Com- 
patibility and composition of web service signatures can be 
computed in linear time. 

Composing web services allows us to reason about the 
behavior exhibited when, for instance, a particular airline 
reservation service S, and a particular hotel reservation ser- 
vice Sn are used as part of a larger system. Note that the 
composition is still an open system. For instance, Sa and Sh 
may both use a credit card processing service Se. Assump- 
tions made about the environment are allowed; the goal is 
to check whether an environment fulfilling such assumptions 
can exist. The airline ticket reservation service and the ho- 
tel room reservation service may make assumptions about 
the behavior they expect of each other, and additionally 
about the credit card processing service in their environ- 
ment, which they both use. Our formalism considers the 
airline and hotel reservation web services compatible as long 
as their mutual behavioral assumptions and guarantees are 
consistent, assuming that a credit card processing service 
fulfilling all expected requirements can exist. Intuitively, 
this is why our formalism is an interface theory [8]. 


EXAMPLE 3. (Compatibility of signatures) Let us 
build the composition of the signature Ssnop with the fol- 
lowing signature for Store: 


Sstore = { 
(ChkStore, OK) +> {(GetOffer, OK), (Order, OK)} 
(ChkStore, FAIL) ++ {(GetOffer, OK), (Order, OK)} 


} 


Both actions require two other actions supported by 
Supplier to order new items if the stock is below a cer- 
tain threshold. Signature Sstore is well-formed. The union 
Ssnop U Sstore is also well-formed because it supports all ac- 
tions for its supported methods and no action is supported 
in both signatures. Therefore the signatures are compatible 
and their composition is Ssnop U Sstore- E 


Substitutivity. To enable top-down design, we want to be 
able to replace a component embedded as part of a larger 
system (its environment) with a new component, while en- 
suring that the entire system still cooperates properly as 
before. Intuitively, we need to ensure that the replacement 
component behaves similarly to the replaced one as far as 
the environment assumptions and guarantees are concerned. 

Given two web service signatures S and S’, we say S’ 
refines S (written S’ < S) if 


i) for every a € A, if S supports a, then S’ supports a, 


ii) for every a,a’ € A, if S supports a, and a requires a’ 
in S’, then a requires a’ in S, and 


iii) for all web methods m not supported by S’, if S’ re- 
quires an action (m,o), then S requires (m, 0). 


The first condition ensures that the refined web service 
signature “guarantees” to support every action supported 
by the abstract one. The other two conditions ensure that 
the refined web service signature does not “assume” addi- 
tional actions to be supported by the environment under 


150 


situations where it is used exactly as the abstract one would 
have been used. Given two web service signatures S and S’, 
the question if S’ < S can be decided in linear time. 


EXAMPLE 4. (Substitutivity of signatures) Let Sgnop 
be a second web service signature defined as 


SShop = { 
(SellItem, SOLD) +> 
(SellItem, FAIL) > 


{(ChkAvail, 0K), (ProcPay, OK) } 

{(ChkAvail, 0K), (ProcPay, OK), 
(ProcPay, FAIL) } 

{(ChkAvail, FAIL) } 

{(ChkStore, OK) } 

{(ChkStore, FAIL) } 


(Se11Item, NOTFOUND) +> 
(ChkAvail, 0K) + 
(ChkAvail, FAIL) + 


} 


Compared with Ssp, the signature SSnop supports an 
additional action (SellItem,NOTFOUND) and requires no 
action for shipping (e.g., because it implements the shipping 
functionality itself). It is a refinement of Ssnop because 
it i) supports all actions which Ssnop supports, ii) these 
“refined” actions require only a subset of the actions which 
are required by the actions in Ssnop, iii) the new action 
requires only actions which are already required by some 
action in Sghop. E 


3. CONSISTENCY INTERFACES 


Let B(P) be the set of expressions over the set of propo- 
sitions P, using the binary operators M and LU, and the 
propositional constant T. Our language of expressions has 
some important properties in common with the language of 
boolean expressions, but there are some essential differences 
which we will point out as appropriate. We use the symbols 
U and M instead of V and A to reflect the similarity, and the 
difference. 

Given a set of actions A, a consistency interface C is a 
partial function C : A — B(A). The element ((m,o),T) € C 
means that interface C supports a method m, and when 
m is called, and the caller expects the outcome to be o, 
the interface C guarantees to fulfill the expectation, since 
C((m, o)) is defined. Further, C provides this guarantee mak- 
ing the assumption T, which is always fulfilled, i.e., action 
(m,o) is supported under no assumptions. Intuitively, this 
means that the code executed when web method m is called 
can lead to the outcome o without calling any other web 
method. The element (a,a’) € C, where a’ = (m’,o’), says 
that the action a is supported by C, and when a is invoked, 
C calls m’ in turn, and expects the outcome o’. The element 
(a, pı N y2) E€ C says that action a is supported by C, and 
leads to the combination of the two sets of conversations, 
one represented by yı and one represented by p2. The ele- 
ment (a, pı U p2) E€ C says that action a is supported by C, 
but can lead to the set of conversations represented by 1, or 
to the set of conversations represented by y2, nondetermin- 
istically chosen by the interface. Allowing nondeterminism 
in interfaces allows us to make them abstract; i.e., the in- 
terface can forget about the implementation details of the 
web service code, and only capture its external behavior in 
terms of patterns of the web method calls it makes. 

Given a consistency interface C, the underlying web ser- 
vice signature of C (denoted by sig(C)) is defined as follows: 
for all a € A, if C(a) is defined, then sig(C)(a) = {a | 
a’ occurs in C(a)}, and sig(C)(a) is undefined otherwise. A 
consistency interface C is well-formed if sig(C) is well-formed. 


In the rest of the paper, “consistency interface” stands for 
“well-formed consistency interface” . 


EXAMPLE 5. (Well-formed consistency interface) 
Let us model the Shop web service as consistency interface: 


Csnop = { 

(SellItem, SOLD) ++ (ChkAvail, OK) M (ProcPay, OK) 
(ShipItem, OK) 
(ChkAvail, FAIL) LI ((ChkAvail, 0K) 
((ProcPay, FAIL) U 


(ProcPay, OK) M (ShipItem, FAIL)) 


(SellItem, FAIL) > 


(ChkAvail, OK) > 
(ChkAvail, FAIL) > 


} 


For action (SellItem, SOLD), all three actions occur together. 
For action (SellItem, FAIL), action (ChkAvail, FAIL) occurs 
alone, or action (ChkAvail, OK) occurs together with either 
action (ProcPay,FAIL) or both, actions (ProcPay, 0K) and 
(ShipItem, FAIL). Note that nothing is said about the or- 
der of their occurrence. The actions for method ChkAvail 
result in calls of the method ChkStore in Store (delegation 
of service). 

The underlying signature sig(Csnop) Of Csnop is Ssnop from 
Example 2, which is a well-formed signature, and hence Cgnop 
is a well-formed consistency interface. | 


ChkStore, OK) 
ChkStore, FAIL) 


mS on 


3.1 Compatibility and Composition 


Intuitively, given two consistency interfaces, if their mu- 
tual behavioral assumptions and guarantees allow them to 
co-operate, we say they are compatible, and we can compose 
them to a single consistency interface, in which some of their 
internal details are forgotten and the combined behavioral 
assumptions and guarantees of interest for the environment 
are retained. 

Given two consistency interfaces Cı and C2, if the under- 
lying signatures sig(C1) and sig(C2) are compatible, then 
Cı and Cz are compatible (denoted by comp(Ci,C2)), and 
their composition (denoted Cı || C2) is Cy U C2. The com- 
position operation is commutative and associative. Com- 
patibility and composition of consistency interfaces can be 
computed in linear time. 


EXAMPLE 6. (Compatibility of consistency inter- 


faces) Consider the following consistency interface for 
Store: 
CstoreF1 = { 


(ChkStore, 0K) — {T U ((GetOffer, REC) M (Order, OK))} 


} 


When action (ChkStore, OK) is invoked, Store does nothing, 
or gets offers and orders more items (if the stock is below 
threshold). Note that nondeterminism allows the stock to 
be abstracted away. 

Let us try to compose the Shop and Store interfaces. 
Are they compatible? No, because their union Ce is not 
a well-formed interface; because Ce supports an action 
(ChkStore, OK) and thus supports method ChkStore, but 
requires an action (ChkStore, FAIL) that is not supported. 
Intuitively, this means that Shop and Store do not agree 
on their mutual guarantees and assumptions, and therefore 
cannot work with each other. 
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The following consistency interface fixes the bug of 
Cstorerı by supporting action (ChkStore, FAIL): 


Cstore = { 
(ChkStore, OK) > {T U ((GetOffer, OK) M (Order, OK) )} 
(ChkStore, FAIL) +> {(GetOffer, 0K) M (Order, OK)} 


The action (ChkStore, 0K) is the same as in Cstorer, and 
for action (ChkStore,FAIL) it orders new items. The 
consistency interfaces Csnop and Cstore are compatible, and 
can be composed to Csnop || Cstore- E 


3.2 Specifications 


The notion of well-formedness removes a general class of 
errors in consistency interfaces. However, depending on the 
particular application in which a service will be used, addi- 
tional properties would be required of it. We identify a class 
of safety properties that seem the most useful in practice and 
propose a property specification language and a verification 
scheme as follows. 

In the context of consistency interfaces, a conversation is 
a set of actions that are exhibited together. Sets of conversa- 
tions are concisely represented using expressions y € B(A). 
Intuitively, the expression T represents the empty conver- 
sation. The expression a (where a is a supported action) 
represents the set of possible conversations exhibited when 
action a is invoked. If ais not supported, then the expression 
a represents the set consisting of only the conversation {a}. 
Thus, we postpone judgement about the behavior exhibited 
by an action a until enough information is available about 
the actions a requires. Intuitively, this is why our formalism 
allows systems to be developed and analyzed incrementally; 
as long as some environment exists in which the (open) sys- 
tem under development can operate correctly, it will be con- 
sidered to be correct. The expression yi U p2 represents a 
nondeterministic choice between yı and p2, and hence rep- 
resents the set consisting of all conversations represented by 
pı or p2. The expression yı M p2 represents the combi- 
nation of the two sets of conversations, i.e., the actions of 
each pair of conversations, one each from yı and p2, can be 
exhibited together in a conversation of pı N p2. 

The set of conversations represented by an expression from 
B(A) is defined by the function [.] : B(A) —> 92” which is 
inductively defined as the least solution of the following sys- 
tem of equations: 


[r] 
[a] 
[a] 
[v1 U ye] 
[yı N ve] {zUy]| z E [yil y € [y2]} 


where a € A and 41, y2 € B(A). 

Note that according to the above definition, the operators 
and N are commutative and associative, and distribute 
over each other, thus acting like the boolean V and ^ oper- 
ators respectively. However, while U is idempotent (like V), 
is not (unlike A). The following example illustrates the 
idea concretely. 


{0} 
{tat Uy |y € [Cla] 


if a € dom(C) 
if ~a € dom(C) 


EXAMPLE 7. (Idempotence) The expression y U » 
represents choice between two completely equivalent alter- 
natives, so L! must be idempotent. Now consider the ex- 
pression y = (a U b) N (aU b). It represents two duplicate 


invocations of (a U b), which make independent choices and 
hence y exhibits a richer set of conversations than a single 
invocation of (a U b). Formally, [(a U b) N (a U b)] = 


{{a}, {a,b}, {ob} A {ta}, {b}} = [a U b]. n 


A specification w for a consistency interface is a formula 
a ¥ S where a E€ A and S C A. Intuitively, a specification 
represents the property that the invocation of action a must 
not lead to a conversation in which the actions in set S' are 
all exhibited together. Formally, a specification 4% = a ¥# S 
is satisfied by a consistency interface C (denoted C = 4) 
if S ¢ y for all y € [C(a)]. The specification satisfaction 
problem for consistency interfaces is in co-NP. 

Given two compatible consistency interfaces Cı 
and C2, and a specification p, then the following holds: 
(Ci || C2) =Y => Ci H YA C2 Ew). The converse is not 
true. 


EXAMPLE 8. (Specification for consistency inter- 
faces) Consider the interface Ce = Csnop || Cstore and the 
following specification %: 


(SellItem, FAIL) * {(ChkStore, FAIL), (ProcPay, OK) } 


The specification requires that the client must not be 
charged for an item which is not available at the store. 
To check whether Ce satisfies Y, we have to compute 
[C.((Se11Item, FAIL))], i.e., 


[(ChkAvail, FAIL) LI ((ChkAvail, 0K) N ((ProcPay, FAIL) U 
((ProcPay, OK) N (ShipItem, FAIL))))], 


which is the following set (of sets): 


{{(ChkAvail, FAIL), (ChkStore, FAIL), 
(GetOffer, OK), (Order, OK)}, 
ChkAvail, OK), (ChkStore, OK), ProcPay, FAIL) $, 
y 
{(ChkAvail, 0K), (ChkStore, OK), (GetOffer, OK), (Order, OK), 
(ProcPay, FAIL)}, 
{(ChkAvail, 0K), (ChkStore, OK), 
(ProcPay, OK), (ShipItem, FAIL) } 
{(ChkAvail, 0K), (ChkStore, OK), (GetOffer, OK), (Order, OK), 
(ProcPay, OK), (ShipItem, FAIL) } 


We observe that there is no y in [C.((SellItem, FAIL))] such 
that {(ChkStore, FAIL), (ProcPay,OK)} C y, and therefore 
(Csnop | Cstore) H= w. i 


EXAMPLE 9. (Non-recursive conversation) Consider 
now the following interface for the Shop web service: 


Conop a { 
(SellItem, SOLD) +> 
(SellItem, FAIL) > 


ChkAvail, OK) M (ProcPay, OK) 
ChkAvail, FAIL) U ( 

ChkAvail, OK) M (ProcPay, FAIL)) 
ChkAvail, FAIL) 

ChkStore, OK) 

ChkStore, FAIL) 


(Sel1Item, NOTFOUND) +> 
(ChkAvail, OK) > 
(ChkAvail, FAIL) + 


} 


Let us compose Chop with the following version of Store: 


ee 


CstoreF2 = { 
(ChkStore, OK) > 
(ChkStore, FAIL) t> 


T U ((GetOffer, OK) M (Order, OK)) 
(SellItem, NOTFOUND) M 
(GetOffer, OK) N (Order, OK) 
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Whenever method ChkStore reports that there are no more 
items available (by action (ChkStore,FAIL)), the Store 
interface notifies the Shop interface that there are no more 
items available. We can check whether the conversations 
of these two web services contain a recursive invocation of 
(ChkStore, FAIL) by checking the following specification on 
the composed interface: 


Wr = (ChkStore, FAIL) + {(ChkStore, FAIL) } 


The property does not hold because (ChkStore, FAIL) in- 
vokes (Se11Item, NOTFOUND) which invokes (ChkAvail, FAIL), 
and this action invokes (ChkStore, FAIL) again. | 


3.3 Substitutivity 


While implementing a web service application, a developer 
often wants to use an off-the-shelf service P’ to implement 
some desired functionality for which she has an abstract 
place-holder P in her overall design. In such situations, it is 
required to decide if P’ fulfills the behavioral requirements 
specified in P, to avoid errors in the overall design. Intu- 
itively, refinement captures the notion of one service being 
substitutable in place of another. 

Given two consistency interfaces C and C’, we say C’ re- 
fines C (written C’ x C) if 


i) sig(C’) x sig(C), and 


ii) for every a € A, if C supports a, then for all conversa- 
tions y € [C’(a)], there exists a conversation x € [C(a)] 
such that y C zx. 


The definition above allows the refinement C’ to drop con- 
versations, or actions from a conversation, for actions sup- 
ported by C; C’ is also allowed to support additional actions 
that C does not, but it is not allowed to require additional 
actions; it can implement actions a not supported by C only 
by requiring actions b already required by C, and that too, 
only as long as it does not introduce a new conversation y 
in C’ for an action c supported by C such that y is not a 
fragment (subset) of a conversation x of c in C itself. 


THEOREM 1. (Substitutivity of consistency inter- 
faces) Let Ci, Ci, and C2 be three consistency interfaces 
such that comp(C1,C2) and comp(C{,C2). Let Y =a S be 
a specification such that a is supported by either Cı or Co. If 
(C1 || C2) | Y and Ci 3 Ci, then (Ci || Co) Ev. 


The above theorem allows a developer to substitute a ser- 
vice C’ in place of an abstract place-holder C in a design, 
if C’ refines C. Thus, our framework allows compositional 
refinement: separate parts of a design can be independently 
refined, say by independent development teams in a paral- 
lelized development environment, or even by separate com- 
panies that do not want to disclose any information about 
their code, without having to worry about global consis- 
tency issues. Once interfaces are decided at the top level, 
they can be handed off to separate development teams to be 
implemented in a more concrete form. As long as the design 
produced by each team is a refinement of the interface it had 
been handed to start with, the design of the entire applica- 
tion is guaranteed to be correct. Formally, for consistency 
interfaces C1, Ci, and C2, if comp(Ci,C2) and comp(Ci, C2) 
and Ci =< Ci, then (Ci || C2) < (Ci || C2). The refinement- 
checking problem for consistency interfaces is in NP. 


EXAMPLE 10. (Substitutivity of consistency inter- 
faces) The interface Csnop (from Example 9) is a refinement 
of interface Cgyop (from Example 5), because i) sig(Cgnop) = 
SShop is a refinement of sig(Csnop) = Ssnop, and ii) actions 
supported in Conop require less actions than those supported 
in Cshop (CSnop does not require the actions for shipping) and 
Cgnop Supports an additional action (SellItem, NOTFOUND), 
which requires only actions already used by Csnop. Apply- 
ing Theorem 1 we conclude that if we replace interface Csnop 
by its refinement Cinop in the composition with the Store 
interface Cstore, the new composition is a refinement of the 
old composition, and the specification ~ from Example 8 is 
satisfied by the new composition: 


(Csnop | Cstore) x (Csnop | Cstore ) and (CSnop | Cstore) H w. |] 


4. PROTOCOL INTERFACES 


Consistency interfaces and the associated specification 
formalism are used to reason about sets of actions. Though 
it is sufficient to catch a large set of web service errors and 
represent many properties of interest, there is often a need 
for a richer model of web service behavior that allows rea- 
soning about evolution of behavior over time. In addition 
to reasoning about sequences of actions, it is important to 
be able to model thread creation, parallel executions of mul- 
tiple threads, and joining threads after a parallel call. We 
introduce the formalism of protocol interfaces which is a rich 
model for representing web service behavior. 

The set of terms over a set of actions A is defined by the 
following grammar (a,b € A): 


term ajaŭb|anb|aHĦb 


A protocol automaton is a tuple F = (Q, 1,6), where Q is 
a set of control locations, L € Q is the return location, and 
ô : (Q\ {1}) > (terms x Q) is the switch function of the 
protocol automaton, which assigns to each location different 
from L a term and a successor location. The execution halts 
when location L is reached. A protocol interface P is a pair 
(D, F), where D : A— 2° is a partial function that assigns 
to an action a set of locations, and F is a protocol automaton. 

The semantics of a protocol interface is presented infor- 
mally as follows. A formal semantics will be presented in 
Section 4.2. Intuitively, the execution of an action a starts 
in one of the locations in D(a). A switch of the automa- 
ton ô(q) (term, q’) means that, if the automaton is in 
location q, it recursively invokes term, and remembers the 
successor location q’ as the return location, where control 
returns when the recursive invocation of term terminates. 
If the automaton reaches location L, it returns control to 
the return location; a return for the very first invocation 
of action a leads to termination of execution. The term 
a = (m, 0) represents a call to web method m with expected 
outcome o. The term a U b represents a nondeterministic 
choice between a and b. The term a M b represents spawning 
two threads for a and b in parallel, while the parent thread 
waits for both to finish. The term a H b represents spawning 
two threads for a and b in parallel, while the parent thread 
waits for whichever child finishes first. Note that all three 
of U, N, and H are commutative, and U is idempotent while 
Mand Æ are not. 

A location q is well-formed if there exists a terminating 
execution of F starting in location q. An action a is 
well-formed if at least one of the locations in D(a) is well- 


153 


formed. To formally define the notion of well-formedness 
of locations, we use a function wf : Q — {T,F}, which is 
inductively defined as follows: 


wf (L) =T. 
uf (q) = a a) ^ uf (q); if 6(q) = (a,q’). 
uf (q) = Ee ents wf (qa) A wf (qv) ) A wf (a'), 

if (q) = (a N b, q’). 
wf (q) = ( wf (da) V wf (qo) ) A f(a’), 


da €P(a),q,ED(b) 


if 6(q) = (a 0 b,q'), o 


{U, B}. 


The function wf can be computed using a least fixed 
point computation (starting from the function that maps 
all locations to F) that converges in time O(n? - k”), where 
n = |Q| is the number of locations of the protocol automa- 
ton and k = maxa(|D(a)|) is the maximal nondeterministic- 
branching factor of the interface. 

Given a protocol interface P = (D, F), the underlying web 
service signature of P (denoted sig(P)) is the partial func- 
tion S : A — 2^ such that S(a) = Ugen(ay St9l(q) if D(a) 
is defined, and S(a) is undefined otherwise. The function 
sigl : Q — 2^ assigns a set of actions to every location 
q € Q of the protocol interface, and is inductively defined 
as follows: sigl(q) = g(term) U sigl(q’) for 6(q) = (term, q’) 
with q # L, and sigl(L) = Ø. The function g : terms > 2^ 
is inductively defined as g(a) = a, glao b) = {a,b} with 
o € {U,0, ŒE}, with a,b E€ A. A protocol interface P is well- 
formed, if sig(P) is well-formed and all actions supported 
by P are well-formed. In the rest of the paper, “protocol 
interface” stands for “well-formed protocol interface”. 


EXAMPLE 11. (Well-formed protocol interface) Let 
us model the Shop web service as a protocol interface. For 
simplicity, protocol interfaces are defined concisely here by 
giving the switch function 6 of the automaton as a sequence 
of triples q : (term,q’), and the partial function D is indi- 
cated by writing an action in front of every location it is 
mapped to. 


Psnop = { 

(SellItem, SOLD) + (ChkAvail, OK), q1) 
(ProcPay, OK), L) 
(ChkAvail, FAIL) 
SellStep1, FAIL), L) 
ChkAvail, OK), qa) 


ProcPay, FAIL) O 


(SellItem, FAIL) > 


(Sel1Step1, FAIL) + 


IN OS 


Sel1Step2, FAIL), |) 

(SellStep2,FAIL)++ qs : ((ProcPay, OK), ge) 
qe : ((ShipItem, FAIL), L) 

(ChkAvail, OK) > q7 : ((ChkStore, OK), L) 
(ChkAvail,FAIL) +> qs: ((ChkStore, FAIL), L) 


} 


Compare this protocol interface with the consistency inter- 
face Csnop; they have a relationship and we will formalize the 
idea in Section 4.4. 

The protocol interface models that for action 
(SellItem, SOLD) the three actions occur in the given se- 
quence in a conversation. When the action (SellItem, FAIL) 
is invoked, Shop nondeterministically can check the avail- 
ability of the item (using ChkAvail) with the expectation 


of failure, or can invoke SellStep1 with the expectation 
of failure. In the latter case, ChkAvail is invoked with 
expectation of success, and then either the payment 
processing web method (ProcPay) or the Sellstep2 web 
method is invoked, in both cases with expectation of failure. 
The invocation of (Sel1Step2, FAIL) leads to a successful 
invocation of the payment processing web method, and then 
a failed attempt to ship the item sold (using ShipItem). 
The protocol interface Psnop is well-formed, because its 
underlying signature is well-formed and all its actions are 
well-formed. | 


EXAMPLE 12. (Concurrency and nondeterministic 
actions) The following interface is the protocol interface 
for the Store web service: 


Pstore E { 
(ChkStore, OK) > 
(ChkStore, OK) > 
(ChkStore, FAIL) t> 


1 

q10 

qio : ((Supp1.GetOffer, REC) M 
(Supp2.GetOffer, REC), q11) 

qi : ((Supp1.0rder, OK) U 
(Supp2.0rder, OK), L) 


} 


Let us first consider action (ChkStore,FAIL). The inter- 
face models for this action that two different supplier web 
services are simultaneously asked to make an offer. This ex- 
ample shows how the protocol interface expresses not only 
sequence, but also concurrency. After both offers are re- 
ceived, the automaton switches to location qii, where the 
Store orders the missing item from one of the two suppli- 
ers. After this action, the automaton switches to the re- 
turn location L, and the conversation induced by action 
(ChkStore, FAIL) terminates. 

The invocation of action (ChkStore, 0K) either immedi- 
ately returns, or orders new items, when the stock is below 
a certain threshold. This is modeled by assigning two differ- 
ent locations to the same action. Note that for ordering new 
items the implementation of (ChkStore, FAIL) is shared. E 


4.1 Compatibility and Composition 


Intuitively, as for consistency interfaces, given two proto- 
col interfaces, if their behavior allows them to co-operate, we 
say they are compatible, and we are able to compose them, 
forgetting their internal distinctions and allowing ourselves 
to focus instead on their behavioral contract with their en- 
vironment. 

Given two protocol interfaces Pı = (Di, Fi) and P2 
(D2, F2), if the underlying signatures sig(Pi1) and sig(P2) 
are compatible, and Qi N Q2 = {1}, and Pe = (De, Fe) 
is a protocol interface, where De = Di U Da, F. (Qi U 
Q2, L, ô1 U ĝ2), where Q; and 6; are the set of locations and 
the switch function of the automaton F; for i € {1,2}, then 
Pı and P2 are compatible (denoted comp(P1, P2)), and their 
composition (denoted by Pı || P2) is Pe. The composition 
operation is commutative and associative. Compatibility 
and composition of protocol interfaces can be computed in 
linear time. 

A protocol interface P is closed if its underlying web ser- 
vice signature sig(P) supports all actions it requires, for- 
mally, Va E€ A: a E€ Rp => a € dom(sig(P)), where 
Rp = {a | da’ E€ A: a €E sig(P)(a’)} is the set of ac- 
tions required by P. An interface that is not closed is called 
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open. Given an open protocol interface P, an environment 
for P is a protocol interface Ep that is compatible with P 
and supports all actions that are required but not supported 
by P. Note that the composition (P || Ep) is closed, and 
Ep is not unique. Intuitively, each Ep represents a design 
context in which P can be used. 


EXAMPLE 13. (Compatibility of protocol interfaces) 
The two protocol interfaces Psnop and Pstore are compatible, 
because their underlying signatures are compatible, their 
protocol automata have no location in common except L, 
and all their actions are well-formed. Thus their composition 
Psnop || Pstore is a protocol interface. E 


4.2 Specifications 


We use a specification language which is capable of ex- 
pressing temporal safety constraints to represent protocol 
properties. In the context of protocol interfaces, a conversa- 
tion is a set of sequences of objects A, where each A is a set 
of actions; intuitively, it is a directed acyclic graph of actions 
that are exhibited in sequence or in parallel. Sets of conver- 
sations are represented by protocol automata, which con- 
cisely represent multi-threaded systems with an unbounded 
number of threads. 

A specification p for a protocol interface is a formula 
a ¥ p where a € A, and y is a temporal formula of the form 
(=C) U B (“not C until B”), with C,B C A. Intuitively, 
a specification a & (~C) U B means that the invocation 
of action a must not lead to a conversation in which an ac- 
tion from the set B occurs before any action from the set C 
has occurred. The expressions y can be extended to allow 
right-associative nesting of U operators, as well as boolean 
combinations of U formulas. We omit such extensions here 
for simplicity of presentation. 

A specification 4 for a protocol interface P is interpreted 
over traces generated by the underlying transition relation 
of P, which is defined as follows. 

Underlying transition relation. Given a finite set of 
symbols L, a (binary) tree t over L is a partial function 
t : B* — L, where B* denotes the set of finite words over 
B = {0,1}, and the domain dom(t) = {p € B* | A(p,1) € t} 
is prefix-closed. Each element from dom(t) represents a node 
of tree t, and each node p is named with the symbol t(p). 
The root is represented by the empty word p. The set of 
child nodes of node p in tree t is denoted by ch(t, p) 
{p | db € B: p'’ = p-b A p' € dom(t)}, where - is the 
concatenation operator. The set of leaf nodes of a tree t is 
leaf (t) = {p € dom(t) | ch(t,p) = Ø}. The set of all trees 
over a finite set L is denoted T(L). 

Given a protocol interface P (D,F), the underly- 
ing transition relation of P is a labeled transition relation 
—>p CT(Q®) x 24Ui{r} x 7(Q®), where the states are trees 
over the tree symbols Q” = Q x {H, 0}, where Q is the set of 
locations of protocol automaton F, and the transitions be- 
tween states are labeled with sets of elements from AU {ret}. 


We write t 4 ¢’ for t, A,t’) € +p. In the rules below, if ac- 
tion c is supported by P, qe is an element of D(c), otherwise 
qe is L. The relation —>p is defined as follows: 


{a} 
= 


e Call: t t’ if there exists a node p such that p € 
leaf (t), t(p) = qo, and 5(q) = (a, q') is a switch of F, 
and t = (t \ {(p,g°)}) U {(p, g'o), (p - 0, qa0)}. 


e Fork: t tep} t if there exists a node p such that p € 


leaf (t), t(p) = qo, and 6(q) = (a N b,q’) is a switch 
of F, and t = (t \ {(p, 40)}) U {(p, g'o), (p : 0, qao), (p: 
1, qvo)}. 

e Choice: t ta t if there exists a node p such that p € 
leaf (t), t(p) = qo, and ô(q) = (a L b, q’) is a switch of 
F, and t = (t\ {(p,40)}) U { (p. q'0), (P: 0, qe0)}, where 
cE {a,b}. 

e Fork-Choice: t on t’ if there exists a node p such 
that p € leaf (t), t(p) = qo, and 6(q) = (a H b, q’) is 
a switch of F, and t’ = (t \ {(p,qo)}) U {(p, q'B), (p- 
0, qa°), (p i 1, qv). 


{ret} 
said 


e Return: t t’ if there exists a node p- b, where 


b € B, such that p-b € leaf (t), t(p- b) = Lo, t(p) = qo, 
and t = t \ {(p-b, Lo)}. 
e Return & Remove Sibling Tree: t aes t’ if there exists 


anode p-b, b € t(p-b) = Lo 
t(p) = qĦ, and 


t= (¢\{(p-p',q'?) |p E }) U{(p, g0)}. 


Intuitively, we have a pushdown system whose state is 
a tree, not a stack (tree with branching out-degree 1). The 
primitives Call, Choice, and Return contribute to pushdown 
behavior, and the primitives Fork and Fork-Choice lead to 
branching in the pushdown state. The leaves of the tree 
represent parallel threads of control. A node p of the tree 
is labeled with an element of Q”, the label representing the 
“return location” where control should reach when all the 
children of node p are removed from the tree. For a Call of 
a supported action, the current location is popped as a leaf 
from the tree, the successor location is first pushed, and then 
one of the locations corresponding to the called action (non- 
deterministically chosen) is pushed as child of the successor 
location. Choice behaves similarly except that it produces 
the successor tree for any of the two actions. In case of a 
Fork and a Fork-Choice, the current location is popped, the 
successor location is pushed, and a branch point is created 
in the state, two locations corresponding to the two parallel 
actions are pushed as children of the successor location. In 
case of Return, a leaf labeled with the return location L is 
popped. If the parent of the return location is the succes- 
sor of a fork-choice term, the whole sibling subtree is also 
removed. In other words, a node with two children result- 
ing from a fork can only be popped if both children were 
popped before, but a node with two children resulting from 
a fork-choice is popped if one of the children was popped. To 
remember this fact in the tree symbols, every control loca- 
tion is paired with a flag from {H,o}. Note that invocations 
of unsupported actions are assumed to immediately return. 

A run of a transition relation is an alternating sequence 
of trees and sets of actions to, A1,t1, Ao,te,..., with Vi € 


aante tizi “3 ti. A trace is the projection of a run 
to its action sets, e.g., for the run to, A1, t1, Ao, t2,..., the 
corresponding trace is A;,A2,...; for a location q, a q-run 
is a run to, Ai,ti,... with to = {(p,q0)}, i.e., a run starting 
from location q; a q-trace is a trace corresponding to a q-run. 

Specification checking. A location q satisfies a tem- 
poral formula (=C) U B (written q = (=C) U B) if there 
exists a q-trace Ai, Á2,... such that there exists a j such 


B such that p-b € leaf (t), 


B* Ad? EQ 
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that Aj N B Æ Q, and for all i < j, we have AANC=9. A 
closed protocol interface P = (D, F) satisfies a specification 
p =a ¥ p (written P H 4) if for all q € D(a), we have 
a o. 

Although we defined the semantics of q = ọ in terms of 
traces of the underlying transition relation, to check satisfi- 
ability in practice we do not compute the transition relation 
because it may be infinite. Instead, we define a set of proof 
rules (cf. Figure 2) and give a polynomial-time algorithm 
(cf. Algorithm 1). Using the proof rules in Figure 2 we induc- 
tively decide judgements IT = q = y where ọ is a temporal 
formula of the form y“ = (=C) U B, or y? = O(-AC). All 
leaves of the proof result from the proof rules “Return 0” 
and “Reached U°”. If a judgement is true, there exists a 
short proof of linear size, and its existence can be decided in 
polynomial time. We explain some of the proof rules below. 

The rule “Return O” at the top of Figure 2 asserts that 
the location L satisfies the property O(7C) i.e., no L-trace 
should contain an element from C; which is true, since the 
t-trace is empty. The “Call O” rule says that if the invo- 
cation of action a does not (recursively) lead to an element 
from C, and a itself is not in C, and furthermore, the suc- 
cessor location q’, where control returns after execution of 
a, does not lead to an element from C’, then the location q, 
at which a is called, never leads to an element of C. The 
rule “Choice O” for the operator U is similar to “Call 0”, 
except that one of the nondeterministically chosen actions 
from the term invoked must fulfill the requirements in the 
antecedent. The remaining rules similarly enforce the se- 
mantics of a recursive system with nondeterministic choice, 
process-spawning and joining, and a pushdown tree store. 


PROPOSITION 1. (Correctness of specification check- 
ing) For a given closed protocol interface P and a specifi- 
cation y =a »} (~C) U B, procedure CheckSpec(P, a, B,C) 
in Algorithm 1 stops with answer YES if P satisfies p, and 
No otherwise. 


Algorithm 1 CheckSpec(P, a, B,C) 
Input: Closed protocol interface P = (D, F), 

Action sets B,C C A, and action a € A 
Output: Yes if P satisfies a 4 (~C) U B, No otherwise 
Variables: Set of judgements S, boolean done 


1: done := F 

2: while (~ done) do 

3: done := T 

4: for each location q of automaton F do 

5: // Try to prove q = O(-C). 

6: if all premises of a rule for q = O(—=C) are in S 
then 

T S := SU {q H= O(~C)} 

8: done := F 

9: // Try to prove q } (~C) U B. 

10: if all premises of a rule for q = (~C) U B are in S 
then 

11: S := SU {q H| (AC) U B} 

12: done := F 

end 
13: if (q = (~C) U B) € S for some q € D(a) then 
14: return No 
end 
15: return YES 


(Return 


FOCO) 
qa FOC) agC g@EOCC) bq) = (a,q'), 

q E OCC) qa € D(a) ay 

qe HOC) c€C gd EOC) 4g) = (aU b,q'),cE {a,b}, 
qE OGO) de € D(c) (Choice O) 
qa O(-C) agC mEO-C) b¢C d EO-C) 4g) =(anb,¢’), (Fork 0) 

q = (=C) qa E D(a), qo € D(b) 

eK OAC) a¢gC b€¢€C qg HOC)  5(q) =(ab,q’),c€ {a,b}, . 
e 4E OCC) i n m 7) {a,b} (Fork-Choice O) 
cE B 5(q) = (c,q) V (lq) = (aob,q’') A cE {a,b} ), 0 

qE CC)UB A. Bee { mB) PEUR AN eee 
a CON ae TOME) TCT Me V (Sla) = (aob,q') A cE {a,b} ), 
7E(-C)UB ne Ha Ef A } q (Reached ut 
qa U(-C) a¢gC qdE(CO)UB êl) = (a,q'), 

q= (-C)UuB qa € D(a) (Call 4 

qc HOC) cgC YF E(-C)UB  4(q)= (aU bq’), cE {a,b}, l 
TAE E de € D(c) (Choice U) 

ga O(-C) agC mEO-C) b¢€C FE(-C)UB slg) =(aNb,¢’), 
qE COJU B qa € D(a), qa € D(b) Rreg 
qc OC) agC bgC d E(O)UB lq) = (aE b,q'),c E {a,b}, 


q= (>C) U B 


(Fork-Choice U) 


Figure 2: Proof rules for specification checking 


The algorithm computes the least fixed point of the set of 
provable judgements w.r.t. the proof rules by starting with 
the empty set of judgements, and trying to prove every still- 
unproven judgement until no new judgements can be proved. 
For every location q, it iterates through the all rules that can 
be used to prove the two judgements q = (~C) U B and 
q (=C). If all antecedents of a rule are already proven, 
the rule is “triggered”, and the consequent is considered 
proven. This corresponds to a leaves-to-root traversal of the 
proof for each judgement, where a proof for a judgement T 
is seen as a tree with I as root, instances of the proof rules 
as internal nodes, and judgements axiomatically known to 
be true, as leaves. Since there are only finitely many proof 
rules for each location, finitely many locations, and finitely 
many judgements, and the algorithm proves at least one new 
judgement in each iteration till the fixed point is reached, the 
procedure must terminate. For each judgement I for which 
a proof exists, a shortest proof p(T) exists. By induction 
over the length of p(T), we conclude that every I for which 
a proof exists, is eventually proved by our algorithm, and 
vice versa. 
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PROPOSITION 2. (Complexity of specification check- 
ing) Given a closed protocol interface P = (D, F), and 
given a specification Yy = a »} (~C) U B, the question if 
P satisfies y can be decided in O(n? - k?) time, where n is 
the number of locations of F, and k = maxaca |D(a)| is the 
maximal nondeterministic-branching factor of P. 


The set operations insertion and membership-checking 
can be done in O(1) time, using, for example, a direct-access 
array of flags, since the number of judgements is bounded. 
A term in a switch can have the form a M b; hence the al- 
gorithm, in the worst case, has to check O(k?) proof rules 
for a location (lines 6 and 10). Line 13 takes O(k) time. 
Therefore, lines 5 to 14 altogether are in O(k”) time. The 
loop over locations (line 4) always makes n iterations. The 
fixpoint iteration (line 2) is executed at most 2n times since 
we have only 2n judgements. Note that for the special case 
when C is empty, the problem reduces to reachability of 
a state where an action from B is invoked, which can be 
decided in linear time. 


EXAMPLE 14. (Specification for protocol interfaces) 
The Shop web service is not allowed to process payments if 
the item to be sold is not available. Therefore, we need to 
check that in Psnop the payment is never processed before 
the availability of the item is checked; this property is ex- 
pressed in the following specification ~: 


(SellItem, FAIL) 4 —{(ChkStore, 0K)} U {(ProcPay, OK) } 


This property is satisfied if none of the conversations of Psnop 
has the following characteristic: it starts with a sequence 
of actions which are all different from (ChkStore, OK), and 
eventually an action (ProcPay,0K) occurs. Note that this 
particular specification is “stronger” than the correspond- 
ing specification we discussed for consistency interfaces: it 
forbids not only the conversations that fail checking of avail- 
ability before payment, but also those that do not check for 
availability at all; and also the desired sequence is enforced. 
Observe that the composition Pe = Psnop || Pstore, along 
with a minimal environment for P. that does not require 
any actions, satisfies the specification w. 

Properties like ~ in general cannot be verified using consis- 
tency interfaces, because consistency interfaces do not keep 
track on the order of actions in conversations. However, a 
subset of the protocol specifications can be checked even 
using consistency interfaces using a relationship between 
consistency and protocol interfaces (intuitively “conserva- 
tive extension”) that will be formalized in Section 4.4. E 


4.3 Substitutivity 


As in the case of consistency interfaces, we want to enable 
the substitution of a protocol interface in a design compris- 
ing a set of web services, with the assurance that the change 
will not allow violation by the combined system of any spec- 
ification that it satisfied before the substitution. Our notion 
of refinement for protocol interfaces is based on simulation 
of labeled transition systems. We first define the notions 
labeled transition system and simulation. Then we describe 
how to build a labeled transition system from the underly- 
ing transition relation of the protocol interface, and define 
refinement of two protocol interfaces based on their labeled 
transition systems. 

A labeled transition system (LTS) TS is a tuple 
(S, Si, L,—), where S the set of states, S; C S is the set 
of initial states, L is the set of labels, and > CSxLxS 
is the transition relation. An LTS TS’ = (S', Sj, L,—') is 
simulated by an LTS TS = (S, Sı, L,—) if there exists a 
relation x C S’ x S such that: 


e for every sı € S, s1 € S", if s1 X si, then for every 


~ 
es l ; bos l 
transition s4 — sh, there exists a transition S1 — S82 
1 2) ’ 
such that s% X se, and 


e for every s’ E€ S}, there exists s € S; such that s’ x s. 


Given a protocol interface P = (D,F) and an action 
a supported by P, the underlying transition system ob- 
tained by invoking a on P (denoted uts(P,a)) is the LTS 
TS = (T(Q®), {{0 = go} | q E€ D(a}, 24}, +p), where 
T(Q™) is the set of trees over the set of labels Q™, and 
Q” = Q x {H,o}, where Q is the set of locations in F, 
and —>p is the underlying transition relation of P defined 
in Section 4.2. Intuitively, it is an LTS with a set of states 
comprising the set of binary trees with nodes labeled with 
elements from Q”, the set of initial states comprising trees 


157 


with a root labeled with an element of D(a), and the tran- 
sition relation >p. 

Given two protocol interfaces 
we say P’ refines P (written P’ 3 P), if 


e sig(P’) x sig(P), and 


P P’, 


and 


e for every action a € A, if P supports a, then the 
LTS TS’ = uts(P’,a) is simulated by the LTS TS = 
uts(P, a). 


Note that for all protocol interfaces P and P’, we have 
P’ x P if and only if (P’ || €3) x (P || E$), where £} 
is the minimal environment of P and P’, which supports 
each action required but not supported by P and P’ with 
an implementation that returns immediately on invocation. 


PROPOSITION 3. (Compositionality of refinement) 
Let Pi, Pi, and P2 be three protocol interfaces such that 
comp(Pi,P2) and comp(Pi, P2). If Pi < Pi, then (Pi || 
P2) 3 (Pi || P2). 


From this proposition it follows that a component-based 
system, after refinement of one component, still satisfies all 
specifications that it satisfied before refinement. 


THEOREM 2. (Substitutivity of protocol interfaces) 
Let Pi, Pi, and P2 be three protocol interfaces such that 
comp(P1,P2) and comp(Pi, P2); and (Pı || P2) and (Pi || 
P2) are both closed. Let y =a ¥ (AC) U B be a specifica- 
tion such that a is supported by Pı. Then, if (Pi || P2) Ew 
and Pi 3 Pa, then (Pi || P2) = wv. 


Note that given protocol interfaces P = (D,F) and 
P’ = (D',F'), deciding the question if P’ < P requires, 
according to the definition of refinement above, checking 
whether the corresponding underlying transition systems are 
in simulation. However, the underlying transition systems 
may be infinite-state systems: there can be an infinite num- 
ber of trees representing the configuration of the parallel 
and sequential action invocations in the multi-threaded sys- 
tem. Our formalism of protocol automata and the under- 
lying transition relation enables visibility of recursion and 
control returns [1], therefore, the problem can be solved 
efficiently as follows. We define a local simulation rela- 
tion on locations: < C Q’ x Q, where Q,Q’ are the sets 
of locations of F and F’, as follows: (q',q) € < if the 
LTS pair TS’ = (T (Q), {{p = q'0}}, 240}, —p) and 
TS = (T(Q®), {{p = q0}}, 2^7} —p) are such that 
TS' x TS. Note that we can compute the relation < us- 
ing a greatest-fixed point computation starting from the set 
of all pairs {(q’,q) | q' location of F’,q location of F} and 
removing pairs (q’,q) when the one-step simulation locally 
fails, i.e., q has no switches to match a term that q’ can 
invoke; until a fixed point is reached and for every action 
a supported by P, for every location q’ € D’(a) there is a 
location q € D(a) such that the pair (q’,q) is in the fixed 
point set, and we conclude simulation holds; or there exists 
at least one action a supported by P such that all the pairs 
{(q,¢ | q € D'(a),q € D(a)} are eventually removed from 
the set of pairs, at which point we conclude that simulation 
fails at some point on invocation of action a. Note that the 
other condition for refinement involves checking refinement 
on the underlying signatures sig(P) and sig(P’), which takes 
linear time. 


PROPOSITION 4. (Complexity of refinement check- 
ing) Given protocol interfaces P (D,F) and P' = 
(D’, F’), the question if P’ < P can be decided in O(c-(|A|+ 
c)) time, where A is the set of actions, c= n-n'-k-k', where 
n and n’ are the numbers of locations in F and F' respec- 
tively, k = maxaea(|D(a)|) and k’ = maxacea(|D’(a)|). 


EXAMPLE 15. (Substitutivity of protocol interfaces) 
Consider the protocol interface Psnop and the following pro- 
tocol interface Pénop: 


Psnop = { 


(SellItem, SOLD) +> q20 : ((ChkAvail, OK), q21) 
q21 : ((ProcPay, OK), L) 
(SellItem, FAIL) > q22 : ((ChkAvail, FAIL) 
SellStep1, FAIL), L 
P. 
(SellStep1, FAIL) — q23 : ((ChkAvail, OK), q24 
q24 : ((ProcPay, FAIL), L) 
(SellStep2, FAIL) + q25 : ((ProcPay, OK), q26) 
q26 : ((ShipItem, FAIL), L) 
(SellItem,NOTFOUND) ++ qo7 : ((ChkAvail, FAIL), L) 
ChkAvail, OK) —> q2s : ((ChkStore, OK), 
ilz 
(ChkAvail, FAIL) > q29 : ((ChkStore, FAIL), L) 


} 


The protocol interface Phop refines interface Psnop be- 
cause the refined version “implements” the abstraction: it 
adds guarantees (it supports (SellItem,NOTFOUND)), and 
removes some nondeterministic choice in the behavior (in 
(SellStep1, FAIL)). Note that the abstraction nondetermin- 
istically generates some traces that cannot be matched by 
the refinement. | 


4.4 Consistency and protocol interfaces 


We have presented in Sections 3 and 4 two different the- 
ories for modeling web service interfaces, with different def- 
initions for composition and refinement. In the following 
discussion we show that the two theories are consistent with 
each other, and that the protocol theory is a conservative 
extension of the consistency theory. 

Given a protocol interface P = (D,F), the underlying 
consistency interface of P (denoted uci(P)) is the partial 
function C : A — B(A) such that C(a) = | liena) uce(a) 
if D(a) is defined, and C(a) is undefined otherwise. The 
function uce : Q — B(A) assigns an expression to every 
location q E€ Q of the protocol interface, and is induc- 
tively defined as follows: uce(q) = f(term) N uce(q’) for 
5(q) = (term, q') with q Æ L, and uce(L) = T. The func- 
tion f : terms — B(A) is inductively defined as f(a) = a, 
flau b)=a U b, and f(aob)=an b with o € {N, E}, and 
a,b € A. Note that sig(uci(P)) = sig(P), as expected, and 
hence for two protocol interfaces Pı and P2, comp(P1, P2) > 
comp(uci(P1), uci(P2)), but the converse is not true. Given 
a protocol specification wp a * (~C) U B, the set 
of underlying consistency specifications of pp is defined as 


ucs(thp) = {a % {b} | b € B}. 


THEOREM 3. (Conservative extension) The theory of 
protocol interfaces is a conservative extension of the theory 
of consistency interfaces. In particular: 


1. Given two compatible protocol interfaces Pı and P2 
such that P1 || P2 is closed, and a protocol specification 


Wp, if uci(P1) || uci(P2) = Ye for every Ype E ucs(pp), 


then P || P2 = Yp. The converse is not true. 
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2. Given protocol interfaces P and P', if P! x P, then 
uct(P’) x uci(P). The converse is not true. 


EXAMPLE 16. (Conservative extension) Consider 
the two compatible protocol interfaces Psnop and Pstore from 
the previous examples in this section, and the following spec- 
ification Yp: 


(SellItem, SOLD) 4 ={} U {(ProcPay, FAIL) } 


This specification requires that a conversation starting with 
(SellItem, SOLD) must not reach the action (ProcPay, FAIL), 
no matter what other actions occur on the way to it. If we 
apply the definition of underlying consistency interface to 
the protocol interfaces Psnop and Pstore, we get the underly- 
ing consistency interfaces uci(Psnop) and uci(Pstore) (which 
are similar to, but not identical to the examples in Sec- 
tion 3). 

The set of underlying consistency specifications for Yp 
is a singleton, it contains the following specification Ye = 


ucs(yp): 
(SellItem, SOLD) * {(ProcPay, FAIL) } 


Theorem 3 states in its first part that if the composition 
uct(Psnop) || wci(Pstore) satisfies all of the underlying con- 
sistency specifications — which is true in our case — then 
the composition Psrop || Pstore satisfies the protocol specifi- 
cation wp. This particular 7, is a reachability specification, 
but in general given a protocol specification that rules out a 
sequence of actions, the conjunction of the underlying con- 
sistency specifications rules out all possible orders of the 
actions from the forbidden sequence. Then, for a protocol 
specification wp, the conjunction /\ ucs(tp) of the underly- 
ing consistency specifications is “stronger” than Wp, which 
forbids a conversation only if the actions occur in one par- 
ticular order. Thus, the ability to reason about sequences 
gives the designer the ability to much more precisely express 
what kinds of behavior are undesired. | 


EXAMPLE 17. (Conservative extension of refine- 
ment) Consider the protocol interfaces Psnop and Pénop 
from the previous examples. We already know that Pnop re- 
fines Psnop. Theorem 3 states in its second part that in this 
case the underlying consistency interfaces fulfill the refine- 
ment relation as well. The underlying consistency interfaces 
of Psnop and Psnop are uci(Psnop) and uci(Psnop), respectively. 
The refinement relation uci(Psnop) < uci(Psnop) holds. Note 
that the underlying consistency interfaces are very similar, 
but not identical to the examples in Section 3. | 


5. RELATED WORK 


The field of modeling web services and their interaction 
protocols has received considerable attention in recent years. 
We will briefly mention some of the related work. 

A variety of formalisms have been proposed for e-business 
conversation models [17], models for control flow [24, 16], 
and to model dynamic contracts between services [6]. A 
high-level programming language for web service implemen- 
tation, XL [10], supports constructs like nondeterministic 
choice and parallel execution. BPEL!, together with WS-C? 
and WS-T®, have emerged as the technology for specifying 


Thttp ://www.ibm.com/developerworks/library/ws-bpel/ 
nttp ://xml.coverpages.org/WS-Coordination200309. pdf 
Shttp ://xml.coverpages.org/WS-Transaction2002. pdf 


interaction protocols between web services. They are built 
on top of the XML-based messaging protocol SOAP“ and 
the interface description language WSDL’. 

Verification of BPEL descriptions using finite-state model 
extraction and the NuSMV model-checker has been pro- 
posed [21]. Temporal logics for compositional reasoning 
about web service interfaces have been proposed [22]. Fu, 
Bultan, and Su studied conversations which occur in com- 
positions of web services [4, 12], and analyzed interactions 
of composed web services by modeling them as conversa- 
tions [13, 14]. An implementation supporting a guarded 
automaton language and using the SPIN model-checker is 
available in WSAT [15]. A similar approach was chosen 
in [19], translating BPEL descriptions of web services into 
Promela, and using the SPIN model-checker to analyze web 
service flow. Unanticipated behaviors were detected in the 
WS-AT® protocol using a temporal specification language 
and model checking [18]. Process interactions have been ver- 
ified using finite-state representations for web service com- 
position [11]. 

A DAML-S"-based semantics has been proposed for web 
services [20]. First-order logic is used to express specifica- 
tions, and web service descriptions are represented as Petri 
nets for simulation, verification, and composition. A CCS- 
based formalism to represent and analyze WSCI descriptions 
has been proposed [3], and the issues of compatibility [23] 
and substitutivity are discussed. 

The protocol interface formalism proposed in this paper 
supports programming and modeling language constructs 
like spawning threads, nondeterministic choice, sequencing, 
recursion, join operations, callbacks, etc., which are sup- 
ported by web service programming or modeling frameworks 
like the .NET framework, or WSCI®. However, while Turing- 
complete programming environments or modeling languages 
suffer from the undecidability of non-trivial properties, tem- 
poral specifications and refinement of our interfaces can be 
algorithmically checked. 
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